home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CD ROM Paradise Collection 4
/
CD ROM Paradise Collection 4 1995 Nov.iso
/
hobby
/
gim_308.zip
/
GIMF.DOC
< prev
next >
Wrap
Text File
|
1994-11-04
|
5KB
|
86 lines
APPENDIX F THE FUTURE OF GIM
Appendix A documents some of the changes that have occurred in GIM in
recent months. These include, for the most part, fixes to bugs that
have been reported, or enhancements that have been suggested, by people
who are using GIM. We expect that this sort of thing will continue, and
we encourage you to report bugs and to suggest enhancements when you
find them. We hope you'll discover (as some of our users have told us
<blush>) that we are prompt and responsive when it comes to making these
kinds of changes.
However, you may notice from reading Appendix A that none of the changes
that are listed there are particularly ground-breaking, earth-shattering
changes to the fundamental design of GIM. There are two principal
reasons for this. The first reason is that GIM (as it stands now) is
fairly stable, and we'd like to keep it that way, and so we'd really
rather not shake things up too much by adding fundamentally different
functionality. But the second, and more important reason, is that the
next generation of GIM is currently in development, and it is our hope
to include many of the fundamental, structural kinds of changes into
that product.
GIM's next generation will involve a major redesign, and we are very
excited about its potential. The principal goals of that version are:
* to eliminate the limits that are currently in place. For
example, in GIM version 2.xx, a person may only have 12
marriages, a family may only have 32 children, and a folder may
have only 32,000 lines of notes altogether. (There are other
limits, but these are the ones that we encounter, or have heard
reported, most often.) We alleviated this somewhat in version
3.xx, by increasing the limit of marriages to 24, and the number
of lines of notes to two billion, but there's no guarantee that
even these limits won't be encountered by somebody someday.
Ultimately, we would like to remove all of these limits, and all
others, making completely lists of persons or lists of families
that are unbounded.
* to add an unlimited number of events to each person and family.
For example, the person edit screen currently allows for birth,
christening, marriage, death, burial, and the four LDS temple
ordinances, and the family edit screen allows for marriage and
LDS temple sealings. But we are very much aware that there are
many more events that should belong in those screens, including
things like adoption, immigration, other religious sacraments,
and so on. Ultimately, we would like to allow for an unending
sequence of events for both persons and families, and to allow
for these events to be from a limitless set of possible events.
(By doing so, we will also do away with the LDS flavor of both
of those screens, by making the LDS ordinances one of several
options, just like any other.)
* to add an unlimited number of single-line identifiers. For
example, the person edit screen currently provides fields for
Ancestral File Number and Reference Number, and also provides a
"code" field, all of which may be used as you see a need for
them. Brian, for example, uses the Reference Number to record
U.S. Social Security numbers. But a better solution would be to
provide an unlimited number of such identifiers, so that Social
Security numbers could be recorded in a field called "Social
Security Number" instead of one called "Reference Number", which
is really a fuzzy and non-specific term. The goal is to provide
identifiers to record not only Social Security numbers, but any
other descriptors which may be needed, such as "country of
origin", "native language", "religious affiliation", and so on.
Beyond these basic goals, the authors are investigating certain other
improvements which may be of value to GIM's users. We invite and
encourage suggestions about what structural changes you would like to
see added to GIM, and now is the best time to propose them, now that
we're deep into the design-and-implementation of this next generation
product.
Oh, and by the way, this is worth mentioning: we're planning for this
next generation product to be a native Microsoft Windows application,
written in Borland C++ version 4.0, possibly also including a native DOS
viewer and editor as a secondary effort, to be used in circumstances
where you're doing genealogy on a computer that doesn't "do" MS-Windows.
This DOS viewer-and-editor would include the traversal screen and the
person and family and notes edit screens, but none of the other stuff
(like GIM LISTS and the Prune and Graft Areas). We mention all of this
so you'll know what we're thinking -- and if you have any thoughts along
these lines, we encourage you to let us know.